The IP Multimedia Subsystem (IMS), as defined by the 3rd Generation Partnership Project (3GPP) standards body, merges telephony and Internet technology by providing an all-IP based architecture for the telecommunications industry. The IMS is based on the Session Initiation Protocol (SIP) and makes heavy use of the protocols defined within the IETF. IMS offers a network of servers and databases that assist a user agent with the task of establishing and managing sessions. IMS uses the term sessions because the connections between users are no longer limited to voice services (a phone call). Sessions may be voice, video, text, or other services connecting two or more user agents together. A representative IMS network is depicted in FIG. 1.
Communications between nodes within an IMS network utilize the Session Initiation Protocol (SIP). SIP is a signaling protocol for Internet conferencing, telephony, presence, events notification, instant messaging, and the like. SIP signaling uses a long-term stable identifier, the SIP Universal Resource Indicator (URI). User equipment (UE) in an IMS refers to a device that contains the SIP User Agent that will initiate or terminate SIP sessions. In particular, one form of UE is a mobile terminal operative to send and receive data across a defined air interface, such as Wideband Code Division Multiple Access (WCDMA).
SIP signaling packets in an IMS network are processed by SIP servers or proxies collectively called Call Session Control Function (CSCF). Different types of CSCFs perform specific functions.
A Proxy-CSCF (P-CSCF) is a SIP proxy that is the first point of contact for an IMS terminal (UE). The P-CSCF may reside in the terminal's H-PLMN or a V-PLMN. In either case, a P-CSCF is assigned to a UE during registration, which does not change for the duration of the registration. All SIP messages to and from the UE pass through the P-CSCF, which can inspect them. The P-CSCF performs authentication and security functions for the UE, and maintains records of communications for billing.
A Serving-CSCF (S-CSCF) is the central SIP proxy in a UE's H-PLMN that performs SIP services and session control. Based on information from a Home Subscriber Server (HSS) database, the S-CSCF handles SIP registrations, in which it binds the UE IP address to a SIP address. The S-CSCF also can intercept and inspect all SIP messages to and from the UE. The S-CSCF decides to which AS SIP messages will be forwarded, to obtain their services. The S-CSCF also provides routing services, typically using Electronic Numbering (ENUM) lookups, and it enforces network operator policies.
An Interrogating-CSCF (I-CSCF) is a SIP proxy located at the edge of an administrative domain. The IP address of the I-CSCF is published in the Domain Name System (DNS) of the domain, so that remote servers can find it, and use it as a forwarding point for SIP packets into the I-CSCF's domain. The I-CSCF retrieves the subscriber location from the HSS, and then routes SIP requests to its assigned S-CSCF.
An IMS network includes a Home Subscriber Server (HSS) that stores the relevant user data including authentication information and service data. As part of the user profile, initial Filter Criteria (iFC) are defined to indicate which application servers are to be invoked based on information in the signaling plane.
An IMS network also includes one or more Application Servers (AS) providing various services, such as audio and video broadcast or streaming, push-to-talk, videoconferencing, games, file sharing, e-mail, and the like. Application Servers are invoked based on the iFCs that are stored in the user profile. The S-CSCF will pass signaling onto an AS if the criteria defined in the iFC are met. Once invoked, the AS can take part in the session and provide additional capabilities.
FIG. 1 is a simplified functional block diagram of an IMS network 10. A UE 12 has associated with it one or more CSCFs (e.g., a P-CSCF, S-CSCF, and/or I-CSCF) 14. The CSCF 14 is connected to various AS 16, 18 providing services. A HSS 20 provides information for Authentication, Authorization and Accounting (AAA) functions.
The Diameter protocol is an advanced, extensible AAA protocol, derived from the industry standard RADIUS (Remote Authentication Dial-In User Service) protocol. Diameter includes numerous enhancements to RADIUS, such as error handling and message delivery reliability. It extracts the essence of the AAA protocol from RADIUS and defines a set of messages that are general enough to form the core of a Diameter base protocol. The various applications that require AAA functions can define their own extensions on top of the Diameter base protocol, and can benefit from the general capabilities provided by the Diameter base protocol.
FIG. 2 depicts a representative prior art call flow for a UE to UE call, in which preconditions are used to avoid a problem known as “ghost ringing.” This is accomplished by ensuring that radio resources are reserved on the calling party's side (UE #1) before alerting the called party (UE #2) The call flow with preconditions of FIG. 2 is extracted from section 5.1.2.3 of 3GPP TR 24.930 V.7.5.0, the disclosure of which is incorporated herein by reference in its entirety.
When the called and calling UEs are mobile satellite terminals, the call flow of FIG. 2 presents several problems. First, if the called UE is located where there is no satellite coverage, such as inside a building, the SIP INVITE message at step 207 will never reach the UE unless the satellite initiates a High Penetration Alert (HPA) page. A HPA page is a paging message transmitted at much higher power than a normal page. The HPA page directs the UE to display a message asking the called party to exit the building (or otherwise move into an area of satellite coverage) to receive the call. One solution is for the satellite Radio Access Network (RAN) to send a HPA page on every SIP INVITE, regardless of session establishment type (e.g. voice calls, messaging). However, this approach severely impacts radio resources.
Additionally, the codec negotiation of steps 217 to 232 result from Network Requested Secondary PDP Context Activation (NRSCPA) on Answer—that is, no PDP context is established until the called party is reached via initial SIP signaling. While NRSCPA on Answer has some advantages in terrestrial networks, such as ensuring that network resources are available and reserved prior to connecting the call, it entails extensive SIP messaging between the two UEs. When a call is established over a satellite, the voluminous exchange of SIP messages not only consumes satellite link bandwidth, it also increases the call setup time.